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Abstract 


This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport 
Layer Security (TLS) protocol version 1.3. 


The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are 
becoming mandatory in China, so this document provides a description of how to use the SM 
algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce 
interworking implementations. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8998. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


This document describes two new cipher suites, a signature algorithm and a key exchange 
mechanism for the Transport Layer Security (TLS) protocol version 1.3 (TLS 1.3) ([RFC8446)]). 
These all utilize several ShangMi (SM) cryptographic algorithms to fulfill the authentication and 
confidentiality requirements of TLS 1.3. The new cipher suites are as follows (see also Section 2): 


CipherSuite TLS_SM4_GCM_SM3 
CipherSuite TLS_SM4_CCM_SM3 


{ 0x00, ƏxC6 }; 
{ 0x00, ƏxC7 }; 


For a more detailed introduction to SM cryptographic algorithms, please see Section 1.1. These 
cipher suites follow the TLS 1.3 requirements. Specifically, all the cipher suites use SM4 in either 
Galois/Counter (GCM) mode or Counter with CBC-MAC (CCM) mode to meet the needs of TLS 1.3 
to have an encryption algorithm that is Authenticated Encryption with Associated Data (AEAD) 
capable. The key exchange mechanism utilizes Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) 
over the SM2 elliptic curve, and the signature algorithm combines the SM3 hash function and the 
SM2 elliptic curve signature scheme. 


For details about how these mechanisms negotiate shared encryption keys, authenticate the peer 
(s), and protect the record structure, please see Section 3. 


The cipher suites, signature algorithm, and key exchange mechanism defined in this document 
are not recommended by the IETF. The SM algorithms are becoming mandatory in China, so this 
document provides a description of how to use them with TLS 1.3 and specifies a profile of TLS 
1.3 so that implementers can produce interworking implementations. 


1.1. The SM Algorithms 


Several different SM cryptographic algorithms are used to integrate with TLS 1.3, including SM2 
for authentication, SM4 for encryption, and SM3 as the hash function. 


SM2 is a set of cryptographic algorithms based on elliptic curve cryptography, including a digital 
signature, public key encryption and key exchange scheme. In this document, only the SM2 
digital signature algorithm and basic key exchange scheme are involved, which have already 
been added to ISO/IEC 14888-3:2018 [ISO-SM2] (as well as to [GBT.32918.2-2016]). SM4 is a block 
cipher defined in [GBT.32907-2016] and now is being standardized by ISO to ISO/IEC 18033-3:2010 
[ISO-SM4]. SM3 is a hash function that produces an output of 256 bits. SM3 has already been 
accepted by ISO in ISO/IEC 10118-3:2018 [ISO-SM3] and has also been described by 
[GBT.32905-2016]. 
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1.2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


Although this document is not an IETF Standards Track publication, it adopts the conventions for 
normative language to provide clarity of instruction to the implementer and to indicate 
requirement levels for compliant TLS 1.3 implementations. 


2. Algorithm Identifiers 


The cipher suites defined here have the following identifiers: 


CipherSuite TLS_SM4_GCM_SM3 
CipherSuite TLS_SM4_CCM_SM3 


{ 0x00, ƏxC6 }; 
{ 0x00, ƏxC7 }; 


To accomplish a TLS 1.3 handshake, additional objects have been introduced along with the 
cipher suites as follows: 


e The combination of the SM2 signature algorithm and SM3 hash function used in the 
Signature Algorithm extension is defined in Appendix B.3.1.3 of [RFC8446]: 


SignatureScheme sm2sig_sm3 = { 0x0708 }; 


e The SM2 elliptic curve ID used in the Supported Groups extension is defined in Appendix 
B.3.1.4 of [RFC8446]: 


NamedGroup curveSM2 = { 41 }; 


3. Algorithm Definitions 


3.1. TLS Versions 


The new cipher suites defined in this document are only applicable to TLS 1.3. Implementations 
of this document MUST NOT apply these cipher suites to any older versions of TLS. 
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3.2. Authentication 


3.2.1. SM2 Signature Scheme 


The Chinese government requires the use of the SM2 signature algorithm. This section specifies 
the use of the SM2 signature algorithm as the authentication method for a TLS 1.3 handshake. 


The SM2 signature algorithm is defined in [ISO-SM2]. The SM2 signature algorithm is based on 
elliptic curves. The SM2 signature algorithm uses a fixed elliptic curve parameter set defined in 
[GBT.32918.5-2017]. This curve is named "curveSM2" and has been assigned the value 41, as 
shown in Section 2. Unlike other public key algorithms based on elliptic curve cryptography like 
the Elliptic Curve Digital Signature Algorithm (ECDSA), SM2 MUST NOT select other elliptic curves. 
But it is acceptable to write test cases that use other elliptic curve parameter sets for SM2; see 
Annex F.14 of [ISO-SM2] as a reference. 


Implementations of the signature scheme and key exchange mechanism defined in this 
document MUST conform to what [GBT.32918.5-2017] requires; that is to say, the only valid 
elliptic curve parameter set for the SM2 signature algorithm (a.k.a. curveSM2) is defined as 
follows: 


curveSM2: A prime field of 256 bits. 


y2=x°+axth 


p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 
FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 
a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 
FFFFFFFF 00000000 FFFFFFFF FFFFFFFC 
b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 
F39789F5 15AB8F92 DDBCBD41 4D940E93 
n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 
7203DF6B 21C6052B 53BBF409 39D54123 
Gx = 32C4AE2C 1F198119 5F990446 6A39C994 
8FE30BBF F266@BE1 715A4589 334C74C7 
Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153 
D@A9877C C62A4740 O2DF32E5 2139F0A0 


The SM2 signature algorithm requests an identifier value when generating or verifying a 
signature. In all uses except when a client of a server needs to verify a peer's SM2 certificate in 
the Certificate message, an implementation of this document MUST use the following ASCII string 
value as the SM2 identifier when doing a TLS 1.3 key exchange: 


TLSv1.3+GM+Cipher+Suite 
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If either a client or a server needs to verify the peer's SM2 certificate contained in the Certificate 
message, then the following ASCII string value MUST be used as the SM2 identifier according to 
[GMT.0009-2012]: 


1234567812345678 
Expressed as octets, this is: 


0x31, 90X32, 0X33, 90X34, 0x35, 0x36, 0X37, 0x38, 
0x31, 90X32, 0X33, 0X34, 0x35, 0X36, 0X37, 90X38 


In practice, the SM2 identifier used in a certificate signature depends on the certificate authority 
(CA) who signs that certificate. CAs may choose values other than the ones mentioned above. 
Implementations of this document SHOULD confirm this information by themselves. 


3.3. Key Exchange 


3.3.1. Hello Messages 


The use of the algorithms defined by this document is negotiated during the TLS handshake with 
information exchanged in the Hello messages. 


3.3.1.1. ClientHello 


To use the cipher suites defined by this document, a TLS 1.3 client includes the new cipher suites 
in the "cipher_suites" array of the ClientHello structure defined in Section 4.1.2 of [RFC8446]. 


Other requirements of this TLS 1.3 profile on the extensions of ClientHello message are as 
follows: 


e For the supported_groups extension, "curveSM2" MUST be included. 

e For the signature_algorithms extension, "sm2sig_sm3" MUST be included. 

e For the signature_algorithms_cert extension (if present), "sm2sig_sm3" MUST be included. 

e For the key_share extension, a KeyShareEntry for the "curveSM2" group MUST be included. 


3.3.1.2. ServerHello 


If a TLS 1.3 server receives a ClientHello message containing the algorithms defined in this 
document, it MAY choose to use them. If so, then the server MUST put one of the new cipher suites 
defined in this document into its ServerHello's "cipher_suites" array and eventually send it to the 
client side. 


A TLS 1.3 server's choice of what cipher suite to use depends on the configuration of the server. 
For instance, a TLS 1.3 server may or not be configured to include the new cipher suites defined 
in this document. Typical TLS 1.3 server applications also provide a mechanism that configures 
the cipher suite preference on the server side. If a server is not configured to use the cipher 
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suites defined in this document, it SHOULD choose another cipher suite in the list that the TLS 1.3 
client provides; otherwise, the server MUST abort the handshake with an "illegal_parameter" 
alert. 


The following extension MUST conform to the new requirements: 


e For the key_share extension, a KeyShareEntry with SM2-related values MUST be added if the 
server wants to conform to this profile. 


3.3.2. CertificateRequest 


If a CertificateRequest message is sent by the server to require the client to send its certificate for 
authentication purposes, for conformance to this profile, the following is REQUIRED: 


° The only valid signature algorithm present in "signature_algorithms" extension MUST be 
"sm2sig_sm3". That is to say, if the server chooses to conform to this profile, the signature 
algorithm for the client's certificate MUST use the SM2/SM3 procedure specified by this 
document. 


3.3.3. Certificate 


When a server sends the Certificate message containing the server certificate to the client side, 
several new rules are added that will affect the certificate selection: 


e The public key in the certificate MUST be a valid SM2 public key. 
e The signature algorithm used by the CA to sign the current certificate MUST be "sm2sig_sm3". 


e The certificate MUST be capable of signing; e.g., the digitalSignature bit of X.509's Key Usage 
extension is set. 


3.3.4. CertificateVerify 


In the CertificateVerify message, the signature algorithm MUST be "sm2sig_sm3", indicating that 
the hash function MUST be SM3 and the signature algorithm MUST be SM2. 


3.4. Key Scheduling 


As described in Section 1.1, SM2 is actually a set of cryptographic algorithms, including one key 
exchange protocol that defines methods such as key derivation function, etc. This document does 
not define an SM2 key exchange protocol, and an SM2 key exchange protocol SHALL NOT be used 
in the key exchange steps defined in Section 3.3. Implementations of this document MUST always 
conform to what TLS 1.3 [RFC8446] and its successors require regarding the key derivation and 
related methods. 


3.5. Cipher 


The new cipher suites introduced in this document add two new AEAD encryption algorithms, 
AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for SM4 cipher in Galois/Counter mode and 
SM4 cipher [GBT.32907-2016] in Counter with CBC-MAC mode, respectively. The hash function for 
both cipher suites is SM3 ([ISO-SM3)). 
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This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AFAD algorithms in a style similar 
to what [RFC5116] used to define AEAD ciphers based on the AES cipher. 


3.5.1. AEAD_SM4_ GCM 


The AEAD_SM4_GCM authenticated encryption algorithm works as specified in [GCM], using SM4 
as the block cipher, by providing the key, nonce, plaintext, and associated data to that mode of 
operation. An authentication tag conforming to the requirements of TLS 1.3 as specified in 
Section 5.2 of [RFC8446] MUST be constructed using the details in the TLS record header. The 
additional data input that forms the authentication tag MUST be the TLS record header. The 
AEAD_SM4_GCM ciphertext is formed by appending the authentication tag provided as an output 
to the GCM encryption operation to the ciphertext that is output by that operation. 
AEAD_SM4_GCM has four inputs: an SM4 key, an initialization vector (IV), a plaintext content, 
and optional additional authenticated data (AAD). AEAD_SM4_GCM generates two outputs: a 
ciphertext and message authentication code (also called an authentication tag). To havea 
common set of terms for AEAD _SM4_ GCM and AEAD_SM4 CCM, the AEAD SM4 GCM IV is 
referred to as a nonce in the remainder of this document. A simple test vector of 
AEAD_SM4_GCM and AEAD_SM4_CCM is given in Appendix A of this document. 


The nonce is generated by the party performing the authenticated encryption operation. Within 
the scope of any authenticated encryption key, the nonce value MUST be unique. That is, the set 
of nonce values used with any given key MUST NOT contain any duplicates. Using the same nonce 
for two different messages encrypted with the same key destroys the security properties of GCM 
mode. To generate the nonce, implementations of this document MUST conform to TLS 1.3 (see 
[RFC8446], Section 5.3). 


The input and output lengths are as follows: 
The SM4 key length is 16 octets. 
The max plaintext length is 236 _ 31 octets. 


The max AAD length is 2851 _1 octets. 
The nonce length is 12 octets. 


The authentication tag length is 16 octets. 
The max ciphertext length is 236 -15 octets. 
A security analysis of GCM is available in [MV04]. 


3.5.2. AEAD_SM4_CCM 


The AEAD_SM4_CCM authenticated encryption algorithm works as specified in [CCM] using SM4 
as the block cipher. AEAD_SM4_CCM has four inputs: an SM4 key, a nonce, a plaintext, and 
optional additional authenticated data (AAD). AEAD_SM4_CCM generates two outputs: a 
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ciphertext and a message authentication code (also called an authentication tag). The formatting 
and counter generation functions are as specified in Appendix A of [CCM], and the values of the 
parameters identified in that appendix are as follows: 

The nonce length n is 12. 

The tag length t is 16. 

The value of q is 3. 
An authentication tag is also used in AEAD_SM4_CCM. The generation of the authentication tag 
MUST conform to TLS 1.3 (See [RFC8446], Section 5.2). The AEAD_SM4_CCM ciphertext is formed 


by appending the authentication tag provided as an output to the CCM encryption operation to 
the ciphertext that is output by that operation. The input and output lengths are as follows: 


The SM4 key length is 16 octets. 
The max plaintext length is 274 _ 4 octets. 
The max AAD length is 264 _ 4 octets. 


924 


The max ciphertext length is + 15 octets. 


To generate the nonce, implementations of this document MUST conform to TLS 1.3 (see 
[RFC8446], Section 5.3). 


A security analysis of CCM is available in [J02]. 


4. IANA Considerations 


IANA has assigned the values {0x00,0xC6} and {0x00,0xC7} with the names "TLS_SM4_GCM_SM3" 
and "TLS_SM4_CCM_SM3" to the "TLS Cipher Suites" registry with this document as reference: 


Value Description DTLS-OK Recommended Reference 

0x00,0xC6 TLS_SM4_GCM_SM3 No No RFC 8998 

0x00,0xC7 TLS_SM4_CCM_SM3 No No RFC 8998 
Table 1 


IANA has assigned the value 0x0708 with the name "sm2sig_sm3" to the "TLS SignatureScheme" 
registry: 


Value Description Recommended Reference 


0x0708  sm2sig_sm3 No RFC 8998 
Table 2 
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IANA has assigned the value 41 with the name "curveSM2" to the "TLS Supported Groups" 
registry: 


Value Description DTLS-OK Recommended Reference 


41 curveSM2 No No RFC 8998 
Table 3 


5. Security Considerations 


At the time of writing, there are no known weak keys for SM cryptographic algorithms SM2, SM3 
and SM4, and no security issues have been found for these algorithms. 


A security analysis of GCM is available in [MV04]. 


A security analysis of CCM is available in [J02]. 
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Appendix A. Test Vectors 


All values are in hexadecimal and are in network byte order (big endian). 
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A.1. SM4-GCM Test Vectors 


Initialization Vector: 00001234567 8000800808ABCD 

Key: 0123456789ABCDEFFEDCBA9876543210 

Plaintext: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB 
CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD 
EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF 
EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA 

Associated Data: FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2 

CipherText: 17F399F@8C67D5EE19D@DC9969C4BB7D 
5FD46FD3756489069157B282BB200735 
D82710CA5C22FOCCFA7CBF93D496AC15 
A56834CBCF98C397B4024A2691233B8D 

Authentication Tag: 83DE3541E4C2B58177E@65A9BF7B62EC 


A.2. SM4-CCM Test Vectors 


Initialization Vector: 00001234567 8000800808ABCD 

Key: 01234567 89ABCDEFFEDCBA9876543210 

Plaintext: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB 
CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD 
EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF 
EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA 

Associated Data: FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2 

CipherText: 48AF93501FA62ADBCD414CCE6034D895 
DDA1BF8F132F042098661572E7483094 
FD12E518CE@62C98ACEE28D95DF4416B 
ED31A2F04476C18BB40C84A74B97DC5B 

Authentication Tag: 16842D4FA186F56AB33256971FA110F4 
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